Information processing device, information processing method, program, information storing medium, information processing system, and management device

ABSTRACT

Provided are an information processing device, an information processing method, a program, an information storage medium, an information processing system, and a management device for allowing a user to request capture of a desired play image. A request section transmits capture condition data representing a condition for capturing a play image that indicates details of a game in progress. A confirmation process execution section performs a confirmation process for capture of the play image appropriate to the condition represented by the capture condition data.

TECHNICAL FIELD

The present invention relates to an information processing device, aninformation processing method, a program, an information storage medium,an information processing system, and a management device.

BACKGROUND ART

Technologies are available for capturing a play image that indicatesdetails of the game in progress. PLT 1 discloses, as an example of suchtechnologies, a technology for capturing a game screen image if a givenscreenshot operation is performed while a game program is underexecution.

CITATION LIST Patent Literature

US Patent Application Publication No. 2009/0118008

SUMMARY Technical Problem

If a user can request capture of a desired play image, it is possiblefor the user to view the desired play image without playing the game byacquiring a captured image of the play image in question from a party towhom capture has been requested. However, the technology described inPLT 1 does not allow a user to request capture of a desired play image.

The present invention has been devised in light of the foregoing, and itis an object of the present invention to provide an informationprocessing device, an information processing method, a program, aninformation storage medium, an information processing system, and amanagement device for allowing a user to request capture of a desiredplay image.

Solution to Problem

In order to solve the above problem, an information processing deviceaccording to the present invention includes a capture condition datatransmission section and a confirmation process execution section. Thecapture condition data transmission section transmits capture conditiondata representing a condition for capturing a play image that indicatesdetails of a game in progress. The confirmation process executionsection executes a confirmation process for capture of the play imageappropriate to the condition represented by the capture condition data.

In one mode of the present invention, the capture condition datatransmission section transmits the capture condition data representing acondition to the effect that, in the game, an event must occur thatrelates to a user who is different from a user using the informationprocessing device and a user using a device adapted to capture the playimage. The confirmation process execution section executes aconfirmation process for capture of the play image in response tooccurrence of the event.

Further, in one mode of the present invention, the informationprocessing device further includes an acceptance section that accepts acaptured image of the play image.

Alternatively, the information processing device further includes anacceptance section that accepts an address of a site that allows acaptured image of the play image to be browsed.

Further, another information processing device according to the presentinvention includes a capture condition data storage section and anotification section. The capture condition data storage section storescapture condition data that represents a condition for capturing a playimage that indicates details of a game in progress. The notificationsection notifies capture of the play image appropriate to the conditionrepresented by the capture condition data.

In one mode of the present invention, the capture condition data storagesection stores the capture condition data representing a condition tothe effect that, in the game, an event must occur that relates to a userdifferent from a user who is notified of capture of the play image and auser using the information processing device. The notification sectionnotifies capture of the play image in response to occurrence of theevent.

Further, in one mode of the present invention, the informationprocessing device further includes a display control section thatindicates, in an identified manner, a portion that relates to a userdifferent from a user who is notified of capture of the play image and auser using the information processing device.

Still further, in one mode of the present invention, the notificationsection transmits a captured image of the play image.

Still further, in one mode of the present invention, the notificationsection transmits an address of a site that allows a captured image ofthe play image to be browsed.

Still further, an information processing method according to the presentinvention includes a step of transmitting capture condition datarepresenting a condition for capturing a play image that indicatesdetails of a game in progress. The information processing method furtherincludes a step of executing a confirmation process for capture of theplay image appropriate to the condition represented by the capturecondition data.

Still further, another information processing method according to thepresent invention includes a step of storing capture condition datarepresenting a condition for capturing a play image that indicatesdetails of a game in progress. The information processing method furtherincludes a step of notifying capture of the play image appropriate tothe condition represented by the capture condition data.

Still further, a program according to the present invention causes acomputer to perform a step of transmitting capture condition datarepresenting a condition for capturing a play image that indicatesdetails of a game in progress. The program further causes a computer toperform a step of executing a confirmation process for capture of theplay image appropriate to the condition represented by the capturecondition data.

Still further, another program according to the present invention causesa computer to perform a step of storing capture condition data thatrepresents a condition for capturing a play image that indicates detailsof a game in progress. The program further causes a computer to performa step of notifying capture of the play image appropriate to thecondition represented by the capture condition data.

Still further, a information storage medium according to the presentinvention is a computer-readable information storage medium that storesa program. The program causes a computer to perform a step oftransmitting capture condition data representing a condition forcapturing a play image that indicates details of a game in progress. Theprogram further causes a computer to perform a step of executing aconfirmation process for capture of the play image appropriate to thecondition represented by the capture condition data.

Still further, another information storage medium according to thepresent invention is a computer-readable information storage medium thatstores a program. The program causes a computer to perform a step ofstoring capture condition data that represents a condition for capturinga play image that indicates details of a game in progress. The programfurther causes a computer to perform a step of notifying capture of theplay image appropriate to the condition represented by the capturecondition data.

Still further, an information processing system according to the presentinvention includes first and second information processing devices. Thefirst information processing device includes a capture condition datatransmission section that transmits, to the second informationprocessing device, capture condition data representing a condition forcapturing a play image that indicates details of a game in progress. Thesecond information processing device includes a capture condition datastorage section and a notification section. The capture condition datastorage section stores the capture condition data. The notificationsection notifies the first information processing device of capture ofthe play image appropriate to the condition represented by the capturecondition data. The first information processing device further includesa confirmation process execution section that executes a confirmationprocess for capture of the play image appropriate to the conditionrepresented by the capture condition data.

Still further, a management device according to the present inventionincludes a capture condition data reception section, a capture conditiondata transmission section, a notification acceptance section, and anotification section. The capture condition data reception sectionreceives capture condition data representing a condition for capturing aplay image that indicates details of a game in progress. The capturecondition data is transmitted from a first information processingdevice. The capture condition data transmission section transmits thecapture condition data to a second information processing device. Thenotification acceptance section receives, from the second informationprocessing device, a notification of capture of the play imageappropriate to the condition represented by the capture condition data.The notification section notifies the first information processingdevice of an instruction to execute a confirmation process for captureof the play image appropriate to the condition represented by thecapture condition data in accordance with reception of the notification.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a diagram illustrating an example of an overall configurationof a game system according to an embodiment of the present invention.

FIG. 2 is a diagram illustrating an example of a request screen.

FIG. 3 is a diagram illustrating an example of request data.

FIG. 4 is a diagram illustrating an example of a list screen.

FIG. 5 is a diagram illustrating an example of agreement request data.

FIG. 6A is a functional block diagram illustrating an example offunctions implemented by a capture request device according to theembodiment of the present invention.

FIG. 6B is a functional block diagram illustrating an example offunctions implemented by a capture notification device according to theembodiment of the present invention.

FIG. 6C is a functional block diagram illustrating an example offunctions implemented by a server according to the embodiment of thepresent invention.

FIG. 7 is a flowchart illustrating an example of steps performed by thecapture request device and the server according to the embodiment of thepresent invention.

FIG. 8 is a diagram illustrating an example of a player list.

FIG. 9 is a flowchart illustrating an example of steps performed by thecapture notification device and the server according to the embodimentof the present invention.

FIG. 10 is a diagram illustrating an example of a screen displaying agame server list.

FIG. 11 is a flowchart illustrating an example of steps performed by agame system according to the embodiment of the present invention.

FIG. 12 is a diagram illustrating an example of a game image.

FIG. 13 is a diagram illustrating an example of a game image.

FIG. 14 is an explanatory diagram schematically illustrating an exampleof software hierarchy of a program executed by a client according to theembodiment of the present invention.

DESCRIPTION OF EMBODIMENTS

A detailed description will be given below of an embodiment of thepresent invention on the basis of the accompanying drawings.

FIG. 1 is a diagram illustrating an example of an overall configurationof a game system 1 according to an embodiment of the present invention.As illustrated in FIG. 1, the game system 1 according to the presentembodiment includes a server 10 and clients 12 (12-1, 12-2, and so on,up to 12-n). The server 10 and the clients 12 are each made up primarilyof a computer. The server 10 and the clients 12 are connected to acomputer network 14 such as the Internet. Then, the server 10 and theclients 12 can communicate with each other.

The server 10 is a server computer that manages data shared by theclients 12. The server 10 includes, for example, a control section 10 a,a storage section 10 b, and a communication section 10 c as illustratedin FIG. 1. The control section 10 a is, for example, aprogram-controlled device such as CPU, handling various informationprocessing tasks in accordance with the program stored in the storagesection 10 b. The storage section 10 b is, for example, storage elementssuch as ROM and RAM and a hard-disk drive. The communication section 10c is, for example, a communication interface that exchanges data withthe clients 12 via the computer network 14. The server 10 transmits andreceives information to and from each of the clients 12 via thecommunication section 10 c.

The clients 12 are computers used by users that are, for example,personal computers, game consoles, TV receivers, portable game devices,portable digital assistants, and so on. In the present embodiment, theprogram of a game played by users is installed in each of the clients12. Then, the user of each of the clients 12 plays the game as a playerthereof. Each of the clients 12 includes, for example, a control section12 a, a storage section 12 b, a communication section 12 c, an outputsection 12 d, and an input section 12 e. The control section 12 a is,for example, a program-controlled device such as CPU, handling variousinformation processing tasks in accordance with the program stored inthe storage section 12 b. The control section 12 a according to thepresent embodiment also includes a GPU (Graphics Processing Unit) thatdraws an image in a frame buffer on the basis of graphics commands anddata supplied from the CPU. The storage section 12 b is, for example,storage elements such as ROM and RAM and a hard-disk drive. The storagesection 12 b stores, for example, programs executed by the controlsection 12 a. Further, a frame buffer area in which images are drawn bythe GPU is reserved in the storage section 12 b according to the presentembodiment. The communication section 12 c is, for example, acommunication interface that exchanges data with the server 10 via thecomputer network 14. Each of the clients 12 transmits and receivesinformation to and from the server 10 and the other clients 12 via thecommunication section 12 c. The output section 12 d is a display sectionsuch as display that outputs information and an audio output sectionsuch as speaker that produces audio output in accordance with aninstruction supplied from the control section 12 a. The input section 12e is, for example, a game controller, a touch pad, a mouse, a keyboard,a microphone, a camera, and so on that outputs details of operationsperformed by the user to the control section 12 a.

In the present embodiment, the user of each of the clients 12 canrequest the users of the other clients 12 to capture a play image thatindicates details of the game in progress. Then, the requested user canaccept a request for capture of the play image. A description will begiven below with focus on a case in which a user B who uses the client12-2 requests a user A who uses the client 12-1 to capture a play imageand the user A agrees to the request. Further, we assume below that theusers A and B play various games respectively as players A and B.

FIG. 2 is a diagram illustrating an example of a request screen forrequesting capture of a play image. The request screen appears on thedisplay when a system screen appears on the display of the client 12-2or when the user B performs a given operation while playing a game. Ifthe user B performs an operation of selecting a cancel button CB in therequest screen illustrated in FIG. 2, the screen appearing on thedisplay is updated to the one that had been appearing immediately beforethe request screen appeared. If the user B specifies a condition forcapturing a play image first and then performs an operation of selectinga register button RB in the request screen illustrated in FIG. 2,request data illustrated in FIG. 3 is registered in the server 10.

The request data is associated with a request for capturing a playimage. As illustrated in FIG. 3, the request data includes a request ID,a requesting player ID, reward data, difficulty data, fulfillment statusdata, and capture condition data.

The request ID is identification information of the request data. In thepresent embodiment, a unique value that does not overlap with the ID ofany other request data managed by the server 10 is specified as arequest ID.

The requesting player ID is identification information of the player whorequested capture of the play image associated with the request data.

The reward data represents a reward gained by the player who hasfulfilled the request. The points represented by each piece of rewarddata correspond, for example, to those used in a game or those requiredto be purchased to play a game. In the present embodiment, users canspecify a reward data value via the request screen illustrated in FIG.2.

The difficulty data represents difficulty involved in fulfilling therequest. In the present embodiment, the difficulty data value is one of“S,” “A,” “B,” and “C,” with “S” being the most difficult, and “A,” “B,”and “C” decreasing in difficulty in this order.

The fulfillment status data represents whether or not the requestrepresented by the request data has been fulfilled. “Fulfilled” isspecified as a fulfillment status data value when the request has beenfulfilled. On the other hand, “Unfulfilled” is specified as afulfillment status data value if the request has yet to be fulfilled. Ifnew request data is registered, “Unfulfilled” is specified as afulfillment status data value for the request data.

The capture condition data represents a condition for capturing a playimage. In the present embodiment, this data includes, for example, titledata, event data, and captured image type data.

The title data represents the game title whose play image is to becaptured. In the present embodiment, users can specify a title datavalue via the request screen illustrated in FIG. 2.

The event data represents the event specified in the request data. Inthe present embodiment, the event data represents the event that takesplace in the game whose title is represented by the title dataassociated with the event data in question in the request data. In thepresent embodiment, users can specify an event data value via therequest screen illustrated in FIG. 2. For example, “Beat player X” isspecified as an event indicated by the event data for the request datawhose request ID is “0104.” In this example, the player X is specifiedas an individual with a bounty by a player B. Thus, as an eventindicated by the event data, an event relating to a player specified asan individual with a bounty such as beating the player in question maybe specified rather than an event relating to a player who requestscapture or a player who agrees to capture.

The captured image type data represents the type of image to becaptured. In the present embodiment, “Movie” or “Still image” isspecified as a captured image type data value. In the presentembodiment, users can specify a captured image type data value via therequest screen illustrated in FIG. 2.

Then, in the present embodiment, the list screen illustrated in FIG. 4is generated on the basis of the request data illustrated in FIG. 3.FIG. 4 is a diagram illustrating an example of a list screen of valuesspecified in the request data for a game A. This screen appears on thedisplay of the client 12-1. The list screen is generated on the basis ofthe request data that includes the title data whose value is “Game A.”

In the list screen, request information RI, each associated with therequest data, is arranged one above the other. The user A can change theorder in which the request information RI is arranged by using apulldown menu arranged in the list screen. In the list screenillustrated in FIG. 4, the request information RI is arranged in theorder of most to least recent from top to bottom. It should be notedthat the request information RI may be arranged in the order of numberof user requests agreed to or a difficulty level. The requestinformation RI arranged in the list screen of FIG. 4 is associated withthe request data whose request ID values are each “0104,” “0103,”“0102,” and “0101.”

The request information RI includes a player icon PI, reward informationRWI, difficulty information DI, and a request details character stringRS. The player icon PI is associated with the requesting player IDincluded in the request data. In FIG. 4, player icons PI(a), PI(b), andPI(c) are arranged that are associated with the players A and B, and C,respectively. The reward information RWI represents the reward indicatedby the reward data included in the request data. The difficultyinformation DI represents the difficulty indicated by the difficultydata included in the request data. The request details character stringRS represents the combination of the event indicated by the event dataand the type indicated by the captured image type data included in therequest data.

It should be noted that, in the present embodiment, the elementsincluded in the request information RI, and in this case, the playericon PI, the reward information RWI, the difficulty information DI, andthe request details character string RS, appear in a manner appropriateto the fulfillment status data value included in the request data. Morespecifically, for example, the luminosity of an element associated withrequest data whose fulfillment status data value is “Unfulfilled” ishigher than that of an element associated with request data whosefulfillment status data value is “Fulfilled.”

Further, in the present embodiment, the request information RI arrangedin the list screen is a link. Then, when the user A performs anoperation of selecting one piece of the request information RI, thismeans that the user A has agreed to the request associated with theselected request information RI. As a result, agreement request dataillustrated in FIG. 5 is stored in the storage section 12 b of theclient 12-1 used by the user A. In the present embodiment, a play imageis captured in the client 12-1 on the basis of the agreement requestdata stored in the client 12-1.

Further, in the present embodiment, the request information RI based onthe request data containing the request of the user A as the player A isarranged in the list screen illustrated in FIG. 4. The list screenappears on the display of the client 12, and the user A uses the client12 in question. Then, in the present embodiment, even if the user Aperforms an operation of selecting the request information RI, the userA cannot agree to the request associated with the request information RIin question. It should be noted that the user A may be able to agree tothe request associated with the request information RI in question whenthe user A performs an operation of selecting the request informationRI.

The agreement request data includes an agreement request ID, arequesting player ID, reward data, difficulty data, title data, eventdata, captured image type data, and timing relationship data asillustrated in FIG. 5.

The agreement request ID is type information of agreement request data.The request ID included in the request data that is associated with theselected request information RI is specified as the agreement request IDin question included in the agreement request data.

The requesting player ID, the reward data, the difficulty data, andcapture condition data included in the agreement request data areassociated with the requesting player ID, the reward data, thedifficulty data, and the capture condition data included in the requestdata, respectively. Then, the values of the data included in the requestdata associated with the selected request information RI are specifiedfor these pieces of data included in the agreement request data.

The timing relationship data represents the relationship in timingbetween occurrence of the event indicated by the event data that isincluded in the agreement request data in question and capture of a playimage. The timing relationship data represents, for example, thedifference in timing between occurrence of the event indicated by theevent data that is included in the agreement request data in questionand capture of a play image. Then, in the present embodiment, a value isspecified for the timing relationship data in accordance with the rulesspecified in advance in the server 10 or the client 12 in question.

A further description will be given of capture of a play image inaccordance with a request agreed to.

In the present embodiment, while a game in which the user of the client12 participates is in progress, a play image that indicates details ofthe game in progress appears on the display of the client 12 in questionat a given frame rate. Then, a copy of the play image that appears onthe display, that is, a copy of the play image drawn in a frame buffer,is written successively to a ring buffer area that is capable of storinga movie for up to 15 minutes and provided at the storage section of theclient 12.

Then, in the present embodiment, when the event indicated by the eventdata that is included in the agreement request data illustrated in FIG.5 occurs while the game in question is being played, a movie made up ofa play image or a series of play images appropriate to the event iscaptured. In the present embodiment as described above, when thecondition for capturing the play image associated with the agreementrequest data is satisfied, a movie made up of a play image or a seriesof play images appropriate to the event is captured. If a play image iscaptured, the captured play image is stored in the storage section 12 bas a captured image. If a movie is captured, the movie in question isencoded first, and then stored in the storage section 12 b as a capturedmovie. A captured movie is made up of a plurality of frame images. Itshould be noted that the frame rate at which a series of play images areappeared on a display may be the same as or different from the framerate of a captured movie stored in the storage section 12 b. Then, thevalue of the fulfillment status data included in the request dataassociated with the request in question is updated to “Fulfilled.”

As described above, how a play image is stored is determined on thebasis of timing relationship data included in agreement request data. Inthe example of FIG. 5, “Three minutes before and after occurrence ofevent” is specified as a timing relationship data value. We assume here,for example, that an event of beating the player X occurs in multiplaywhile the user A is playing the game A. In this case, a captured moviebased on play images that appear from three minutes before to threeminutes after the occurrence of the event is stored in the storagesection 12 b of the client 12-1. It should be noted that if, in thepresent embodiment, the captured image type data value is “Movie,” acaptured movie is stored in the storage section 12 b, and if thecaptured image type data value is “Still image,” a captured image isstored in the storage section 12 b.

In the present embodiment, a captured image or movie is associated withmetadata and stored in the storage section 12 b. Here, the metadataincludes, for example, values of event data included in capturecondition data, date and time indicating the time of occurrence of anevent, and so on.

Then, in the present embodiment, the capture of a play image asdescribed above is notified to the user, the player associated with therequesting player ID included in the agreement request data, and here,for example, the user B. It should be noted that how the user B isnotified does not specifically matter. For example, information to theeffect that a play image has been captured may appear on the outputsection 12 d of the client 12-2 used by the user B. Further, forexample, an email stating that a play image has been captured may betransmitted to the mail address of the user B. Still further, anapplication that can receive the above notification may be installed inthe smartphone owned by the user B. Then, the capture of the play imagemay be notified to the user B via a network service to which theapplication connects. Further, at this time, the captured image or moviemay be transmitted to the user B in question.

Still further, in the present embodiment, the captured image or moviestored in the storage section 12 b of the client 12 can be uploaded toimage posting sites and various other Internet sites. Then, such anuploaded captured image or movie is published, for example, to the user,the player associated with the requesting player ID included in theagreement request data. In this case, the address, such as the URL, ofthe site to which the captured image or movie has been uploaded may betransmitted to the user B when the play image is captured.

Then, when the user who made the request in question, and here, the userB, performs a given confirmation operation that represents the requesteda play image has captured, a confirmation notification for the captureof a play image is transmitted to the server 10. Upon receipt of theconfirmation notification, the server 10 issues a reward to the client12-1 used by the user A. Then, the receipt of the reward is indicated onthe display of the client 12-1.

We also assume that when the list screen illustrated in FIG. 4 appears,the user A performs an operation of selecting the request information RIassociated with request data whose fulfillment status data value is“Fulfilled.” As a result, in the present embodiment, the captured movieor image appropriate to the request in question appears, for example, onthe display or the like. For example, the client 12 used by the user Amay download a captured movie or image that has been uploaded to anInternet site and indicate the movie or image, for example, on a displayor the like when the request in question is fulfilled. The operation ofselecting the request information RI associated with request data whosefulfillment status data value is “Fulfilled” will be hereinafterreferred to as a fulfilled request selection operation. Further, whenthe user A performs a fulfilled request selection operation for therequest information RI associated with request fulfilled by the user Ahimself or herself, a captured movie or image appropriate to the requestin question may appear, for example, on a display. Further, after a playimage captured in response to a fulfilled request selection operation,the play image in question, or the URL to which the play image inquestion has been uploaded, may be transmitted to the user who requestedcapture of the play image in question.

Further, in the list screen that appears on the display of the client12, the request information RI based on request data containing therequest of the user using the client 12 in question and the requestinformation RI based on request data containing the request of otheruser may be arranged in different manners. For example, the requestinformation RI based on the request data containing the request of theuser using the client 12 in question and the request information RIbased on the request data containing the request of other user mayappear in different frames.

Still further, users may be allowed to change the condition representedby capture condition data included in the request data that contains therequest of the user in question. This makes it possible, for example, tochange the condition represented by capture condition data to the onethat is more likely to be fulfilled, that is, the condition that is lessdifficult if the condition is hardly likely to be fulfilled.

In the present embodiment, the user B can request capture of a desiredplay image to other user as described above. Then, when the user Aagrees to the request in question and captures the play image inquestion, the capture is notified to the user B. Thus, in the presentembodiment, users can request capture of their desired images to otheruser. More specifically, in the above example, capture of a play imagecan be requested to other user when an event relating to a playerspecified as an individual with a bounty occurs such as when the playerspecified as an individual with a bounty is beaten, for example.

Further, in the present embodiment, if an event indicated by the eventdata included in the agreement request data occurs in the client 12-1,the client 12-1 is controlled in such a manner as to capture a playimage appropriate to the event. For this reason, in the presentembodiment, as long as a request is agreed to, a play image appropriateto the request is captured without one having to perform any explicitoperation for the capture.

A further description will be given below of requesting capture of aplay image, agreeing to the request, capturing a play image, andnotifying capture of a play image.

FIG. 6A is a functional block diagram illustrating an example offunctions implemented by the client 12 according to the presentembodiment that requests capture of a play image to other user. Itshould be noted that not all the functions illustrated in FIG. 6A needto be implemented by the client 12 according to the present embodiment,and that functions other than those illustrated in FIG. 6A may beimplemented. The client 12 that requests capture of a play image toother user will be hereinafter referred to as a capture request device.

The capture request device according to the present embodimentfunctionally includes, for example, a request section 20, a requestpass/fail acceptance section 22, a capture notification acceptancesection 24, a confirmation process execution section 26, and a displaycontrol section 28. The request section 20, the request pass/failacceptance section 22, and the capture notification acceptance section24 are primarily implemented as the communication section 12 c. Theconfirmation process execution section 26 is primarily implemented asthe control section 12 a, the communication section 12 c, and the outputsection 12 d. The display control section 28 is primarily implemented asthe control section 12 a, the storage section 12 b, and the outputsection 12 d.

FIG. 6B is a functional block diagram illustrating an example offunctions implemented by the client 12 according to the presentembodiment that agrees to a request for capture of a play image fromother user and captures a play image. It should be noted that not allthe functions illustrated in FIG. 6B need to be implemented by theclient 12 according to the present embodiment, and that functions otherthan those illustrated in FIG. 6B may be implemented. The client 12 thatagrees to a request for capture of a play image from other user andcaptures a play image will be hereinafter referred to as a capturenotification device.

The capture notification device according to the present embodimentfunctionally includes, for example, an agreement request data storagesection 30, a request search section 32, an agreement processing section34, a game process execution section 36, a display control section 38, adetection section 40, a capture control section 42, a captured imagestorage section 44, a capture notification section 46, and a rewardreception section 48. The agreement request data storage section 30 andthe captured image storage section 44 are primarily implemented as thestorage section 12 b. The request search section 32 and the agreementprocessing section 34 are primarily implemented as the control section12 a and the communication section 12 c. The game process executionsection 36 and the detection section 40 are primarily implemented as thecontrol section 12 a. The display control section 38 is primarilyimplemented as the control section 12 a, the storage section 12 b, andthe output section 12 d. The capture control section 42 is primarilyimplemented as the control section 12 a and the storage section 12 b.The capture notification section 46 and the reward reception section 48are primarily implemented as the communication section 12 c.

It should be noted that the functions of both the capture requesting andnotification devices may be implemented in the single client 12.

Then, the above functions are implemented as a result of execution of aprogram installed in the client 12, a computer, and includinginstructions corresponding to the above functions by the control section12 a of the client 12. The program may be supplied to the client 12 viaa computer-readable information storage medium such as an optical disc,a magnetic disk, a magnetic tape, a magneto-optical disc, or a flashmemory. Further, the program may be supplied to the client 12 via acomputer network such as the Internet.

The request section 20 of the capture request device transmits, to theserver 10, a request for capture of a play image to other user. In thepresent embodiment, the capture request in question is associated withthe above capture condition data. Thus, the request section 20 serves asa capture condition data transmission section that transmits capturecondition data representing a condition for capture of a play image inthe present embodiment. Further, the request section 20 may transmitcapture condition data representing a condition to the effect that, inthe game, an event must occur that relates to a user specified as anindividual with a bounty.

The request pass/fail acceptance section 22 of the capture requestdevice accepts data indicating whether or not the server 10 has accepteda capture request from the request section 20.

The capture notification acceptance section 24 of the capture requestdevice accepts a notification to the effect that the play image whosecapture was requested has been captured. Further, the capturenotification acceptance section 24 may accept a notification to theeffect that a play image appropriate to an event is captured when anevent occurs that relates to a user specified as an individual with abounty. Further, the capture notification acceptance section 24 mayaccept a captured image or movie as described above. Still further, thecapture notification acceptance section 24 may accept an address of asite where a captured image or movie can be browsed as described above.

The confirmation process execution section 26 of the capture requestdevice executes a confirmation process for capture of a play imageappropriate to the condition represented by the capture condition data.In the present embodiment, for example, the confirmation processexecution section 26 of the capture request device transmits, to theserver 10, a confirmation notification for capture of the play image inresponse to a given confirmation operation by the user. Further, in thepresent embodiment, for example, the confirmation process executionsection 26 of the capture request device indicates the captured image ormovie, a play image captured in response to the request, on a display orother device in accordance with the fulfilled request selectionoperation. Thus, a possible confirmation process in the presentembodiment would be to transmit a confirmation or indicate a capturedplay image or the like. Further, the confirmation process executionsection 26 may execute a confirmation process for capture of a playimage in response to an event relating to a player specified as anindividual with a bounty.

The display control section 28 of the capture request device generates arequest screen illustrated, for example, in FIG. 2, indicating thescreen on the display.

The agreement request data storage section 30 of the capturenotification device stores agreement request data illustrated in FIG. 5.Thus, the agreement request data storage section 30 serves as a capturecondition data storage section that stores capture condition datarepresenting a condition for capturing a play image in the presentembodiment.

The request search section 32 of the capture notification devicesearches the server 10 for request data. For example, the request searchsection 32 transmits, to the server 10, a search condition for requestdata. Then, the request search section 32 receives request data thatmatches the search condition from the server 10. Thus, the requestsearch section 32 serves as a capture condition data reception sectionthat receives capture condition data representing a condition forcapturing a play image in the present embodiment. Further, the requestsearch section 32 may receive capture condition data representing acondition to the effect that an event must occur that relates to a userspecified as an individual with a bounty.

The agreement processing section 34 of the capture notification devicegenerates agreement request data on the basis of request data selectedby the user using the capture notification device from among thosepieces of request data received by the request search section 32,storing the generated agreement request data in the agreement requestdata storage section 30. Further, the agreement processing section 34transmits, to the server 10, the agreement request ID included in thegenerated agreement request data.

The game process execution section 36 of the capture notification deviceexecutes the game program installed in the client 12.

The display control section 38 of the capture notification devicegenerates a play image at a given frame rate in accordance with theexecution status of the game program by the game process executionsection 36, indicating the generated play image on a display. Further,the display control section 38 writes a copy of the play image displayedas described above to the ring buffer area.

The detection section 40 of the capture notification device detects anevent that occurs during a game play. In the present embodiment, thedetection section 40 detects an event that occurs in the game as aresult of execution of the game program by the game process executionsection 36. It should be noted that the detection section 40 may detectthe event in question by accepting information, notified by the gameprocess execution section 36, to the effect that the event in questionmust occur. Further, the detection section 40 may detect an event byverifying at a given frame rate whether or not the event in question hasoccurred.

The capture control section 42 of the capture notification deviceidentifies a capture timing in response to detection of an event by thedetection section 40 on the basis of the timing relationship data,controlling capture so that a play image is captured at the capturetiming in question. In the present embodiment, the capture controlsection 42 captures a play image at the identified capture timing,storing the play image in the captured image storage section 44. Here,if the captured image type data value included in the capture conditiondata is “Movie,” the captured movie is stored. If the captured imagetype data value is “Still image,” the captured image is stored. Further,the capture control section 42 associates metadata with a captured movieor image as described above, storing the movie or image in the capturedimage storage section 44.

The captured image storage section 44 of the capture notification devicestores images captured by the capture control section 42. In the presentembodiment, captured movies and images associated with metadata arestored.

The capture notification section 46 of the capture notification devicenotifies capture of a play image that satisfies the conditionrepresented by the capture condition data that is included in theagreement request data. It should be noted that a capture notificationof a play image may be, for example, indicated on the display of thecapture notification device when the image is captured. Morespecifically, for example, the capture notification section 46 mayindicate, on the display, that a play image has been captured. Thismakes the user using the capture notification device aware of capture ofa play image. Further, the capture notification section 46 may notifythat a play image appropriate to an event is captured when an eventoccurs that relates to a user specified as an individual with a bounty.Still further, the capture notification section 46 may transmit acaptured image or movie as described above. Still further, the capturenotification section 46 may transmit the address of a site where acaptured image or movie can be browsed as described above.

The reward reception section 48 of the capture notification devicereceives a reward from the server 10.

FIG. 6C is a functional block diagram illustrating an example offunctions implemented by the server 10 according to the presentembodiment. It should be noted that not all the functions illustrated inFIG. 6C need to be implemented by the client 12 according to the presentembodiment, and that functions other than those illustrated in FIG. 6Cmay be implemented.

The server 10 according to the present embodiment functionally includes,for example, a request data storage section 50, a request acceptancesection 52, a request data management section 54, a request searchresponse section 56, a capture notification acceptance section 58, acapture notification section 60, a confirmation notification acceptancesection 62, and a reward issuance section 64. The request data storagesection 50 is primarily implemented as the storage section 10 b. Therequest acceptance section 52, the request search response section 56,the capture notification acceptance section 58, the capture notificationsection 60, and the confirmation notification acceptance section 62 areprimarily implemented as the communication section 10 c. The requestdata management section 54 and the reward issuance section 64 areprimarily implemented as the control section 10 aand the communicationsection 10 c. Then, as described above, the server 10 according to thepresent embodiment serves as a capture management device that managesrequests for and agreement to capture and notification of play imagecapture.

Then, the above functions are implemented as a result of execution of aprogram installed in the server 10, a computer, and includinginstructions corresponding to the above functions by the control section10 aof the server 10. The program may be supplied to the server 10 via acomputer-readable information storage medium such as an optical disc, amagnetic disk, a magnetic tape, a magneto-optical disc, or a flashmemory. Further, the program may be supplied to the server 10 via acomputer network such as the Internet.

The request data storage section 50 of the server 10 stores request dataillustrated in FIG. 3.

The request acceptance section 52 of the server 10 accepts a capturerequest from the request section 20 of the capture request device. Thus,the request acceptance section 52 serves as a capture condition datareception section that receives capture condition data representing acondition for capturing a play image from the capture request device inthe present embodiment.

The request data management section 54 of the server 10 handles taskssuch as generating and updating request data and storing request data inthe request data storage section 50.

The request search response section 56 of the server 10 searches therequest data storage section 50 for request data on the basis of asearch condition accepted from the request search section 32 of thecapture notification device. Then, the request search response section56 transmits the request data, the search result, to the capturenotification device. Thus, the request search response section 56 servesas a capture condition data transmission section that transmits capturecondition data to the capture notification device.

The capture notification acceptance section 58 of the server 10 accepts,from the capture notification device, a notification of capture of aplay image that satisfies the condition represented by the capturecondition data that is included in the agreement request data.

The capture notification section 60 of the server 10 notifies thecapture request device of an instruction to confirm the capture of theplay image in question in response to acceptance of the notification. Inthe present embodiment, the capture notification section 60 notifies thecapture request device that the play image in question has beencaptured.

The confirmation notification acceptance section 62 of the server 10accepts the confirmation notification for the capture of the play imagefrom the confirmation process execution section 26 of the capturerequest device.

The reward issuance section 64 of the server 10 issues a reward to theuser using the capture notification device in response to acceptance ofthe confirmation notification for the capture of the play image by theconfirmation notification acceptance section 62 of the server 10.

A description will be given here of an example of a flow of a requestregistration process performed by the capture request device and theserver 10 according to the present embodiment with reference to theflowchart illustrated in FIG. 7. We assume here that the user B uses theclient 12-2 as a capture request device.

First, the request section 20 of the capture request device generatescapture condition data and reward data in response to a requestregistration operation performed by the user B (S101).

In the present embodiment, for example, the request section 20 generatescapture condition data and reward data in response to an operation ofselecting the register button RB in the request screen illustrated inFIG. 2 on the basis of the values entered in the request screen. In theexample of FIG. 2, capture condition data is generated that includestitle data whose value is “Game A,” event data whose value is “Whenplayer X is beaten in multiplay,” and captured image type data whosevalue is “Movie.” Further, reward data is generated that has “100points” as its value.

Then, the request section 20 transmits, to the server 10, a capturerequest that is associated with identification information of the playerwho is the user of the client 12 in question and capture condition dataand reward data generated in the step of S101. Here, identificationinformation of the player who is the user of the client 12 in questionis, for example, “Player B.” The request acceptance section 52 of theserver 10 accepts the capture request in question (S102). Then, therequest data management section 54 determines whether or not to registerrequest data including capture condition data associated with thecapture request accepted in the process illustrated in S102 on the basisof the capture condition data in question (S103).

Here, for example, the request data management section 54 confirmswhether or not request data that includes, as capture condition data, avalue identical or similar to that of the capture condition dataaccepted in the step of S102 is already stored in the request datastorage section 50. Then, if it is confirmed that request data is notstored, the request data management section 54 determines that therequest data in question is to be registered. If not, the request datamanagement section 54 determines that the request data is not to beregistered.

Then, if determining that request data is not to be registered (N inS103), the request data management section 54 transmits, to the capturerequest device, data indicating that the server 10 did not accept thecapture request. The data in question indicates, for example, that therequest is to be checked again and that the request has been dismissed.Then, the request pass/fail acceptance section 22 of the capture requestdevice accepts the data in question (S104).

On the other hand, when determining that request data is to beregistered (Y in S103), the request data management section 54 generatesrequest data and stores the request data in question in the request datastorage section 50 (S105). Here, for example, request data is generatedthat includes capture condition data and reward data associated with thecapture request accepted in the step of S102. A unique value that doesnot overlap with the request ID of any other request data is specifiedas a request ID included in the request data in question. Further,identification information associated with the capture request acceptedin the step of S102 is specified as a requesting player ID included inthe request data in question. “C” is specified, for example, as adifficulty data value in the present embodiment.

Then, the request data management section 54 transmits, to the capturerequest device, data indicating that the server 10 accepted the capturerequest. Then, the request pass/fail acceptance section 22 of thecapture request device accepts the data in question (S106).

Then, the display control section 28 of the capture request deviceindicates whether or not capture is possible on the display (S107),terminating the process illustrated in the present example. Here, forexample, if the request pass/fail acceptance section 22 accepts dataindicating that the server 10 did not accept the capture request in thestep of S104, the display indicates that the request is to be checkedagain and has been dismissed. On the other hand, when the requestpass/fail acceptance section 22 accepts data indicating that the server10 accepted the capture request in the step of S106, the displayindicates, for example, that the request has been registered.

In the present embodiment, the request data management section 54 holds,for each piece of the request data stored in the request data storagesection 50, data representing the number of users who have accepted therequest associated with the request data in question and datarepresenting the times when the request data in question wereregistered. Then, the request data management section 54 determines, atgiven time intervals, a difficulty data value for each piece of therequest data stored in the request data storage section 50 on the basisof, for example, the number of users who have accepted the requestassociated with the request data in question and the elapsed times afterthe registration of the request data in question. For example, adifficulty data value is determined so that the greater the number ofusers who have accepted the request associated with the request data inquestion, and the longer the time from the registration, the higher thedifficulty. Then, if the value determined is different from the currentvalue, the request data management section 54 updates the difficultydata value in question to the one determined. Further, the request datamanagement section 54 may increase the points represented by the rewarddata by a given increment when the difficulty data is updated to ahigher difficulty level. It should be noted that a difficulty data valuemay be determined so that the greater the number of users who haveaccepted the request associated with the request data in question, thehigher the difficulty. Further, a difficulty data value may bedetermined so that the longer the time from the registration, the higherthe difficulty.

The user interface used to request capture of a play image is notlimited to the above. For example, as illustrated in FIG. 8, capture ofa play image may be requested via a player list that appears as a systemscreen of the client 12. FIG. 8 illustrates an example of a list ofplayers who beat the player B. The player list appears on the display ofthe client 12-2. Here, for example, when an operation is performed toselect the player X and the select button SB, capture condition datawhose event data value is “When player X is beaten in multiplay” may begenerated in the step of S101. Then, in the step of S105, request datawhose request ID value is “0104” illustrated in FIG. 3 may be registeredin the server 10. In this case, the player X is specified as anindividual with a bounty by the player B. Thus, an individual with abounty may be specified via the player list illustrated in FIG. 8.

A description will be given next of an example of a flow of a requestagreement process performed by the capture notification device and theserver 10 according to the present embodiment with reference to theflowchart illustrated in FIG. 9. We assume here that the user A uses theclient 12-1 as a capture request device.

First, the request search section 32 of the capture notification devicetransmits a search condition to the server 10. Then, the request searchresponse section 56 of the server 10 accepts the search condition(S201). In the present embodiment, the search condition to betransmitted is determined in the step of S201 in accordance with ascreen that presents request data to the user A. The screen appears inthe step of S204 which will be described later. For example, when thelist screen illustrated in FIG. 4 appears, a search condition statingthat “The title data value is ‘Game A’” is transmitted.

Then, the request search response section 56 of the server 10 identifiesrequest data that provides a search result that satisfies the searchcondition accepted in the step of S201 from among the request datastored in the request data storage section 50 (S202). Then, the requestsearch response section 56 transmits the request data identified in thestep of S202 to the capture notification device. As a result, therequest search section 32 of the capture notification device accepts therequest data in question (S203).

Then, the display control section 38 of the capture notification devicegenerates a screen for presenting request data to the user A on thebasis of the request data accepted in the step of S203, indicating thescreen on the display (S204). Here, for example, a list screenillustrated in FIG. 4 appears.

Here, when the user A performs an operation of selecting request data toaccept, the agreement processing section 34 of the capture notificationdevice generates agreement request data based on the selected requestdata, storing the request data in the agreement request data storagesection 30 (S205). The relationship between the selected request dataand agreement request data is as described earlier. Here, request dataselection operation corresponds, for example, to the operation ofselecting the request information RI when the list screen illustrated inFIG. 4 appears. In this case, agreement request data is generated thatis based on the request data associated with the request information RIin question.

Then, the display control section 38 of the capture notification deviceindicates, on the display, that the request associated with theagreement request data generated in the step of S205 has been accepted(S206).

The agreement processing section 34 of the capture notification devicetransmits, to the server 10, the agreement request ID included in theagreement request data that was generated in the step of S205, and therequest data management section 54 of the server 10 receives theagreement request ID in question (S207). Then, the request datamanagement section 54 increments, by 1, the value of data representingthe number of users who have accepted the request data (S208),terminating the process illustrated in the present example. The requestdata includes, as a request ID, the agreement request ID held by therequest data management section 54.

It should be noted that the search condition transmitted to the server10 is not limited to the above. For example, a search conditionspecified by the user A may be transmitted in the step of S201.

A search condition appropriate to the status of the game played by theuser A as the player A may be transmitted in the step of S201. Morespecifically, for example, a search condition may be transmitted in thestep of S201. The search condition states that data is included thatrepresents an event in the stage or map in which the user is playing. Inthis case, for example, a play image of the game in question with therequest information RI arranged therein may appear in the step of S204.

Further, request data may be actively transmitted to the capturenotification device in response to the status of the game played by theuser A rather than in response to acceptance of a search condition. Inthis case, for example, the request information RI associated withreceived request data may be arranged in a play image.

Further, for example, a screen indicating a list of game servers thatcan communicate with the client 12 illustrated in FIG. 10 may bedisplayed by the step of S204. In this case, in the step of S201, asearch condition may be transmitted in the step of S201. The searchcondition includes event data representing an event of beating a playerplaying in one of the game servers displayed in the screen in question.

Then, in the step of S204, the display control section 38 may exercisecontrol so that a star symbol is arranged to the left of the name ofeach game server in which the player is indicated as an opponent to beatin the event data included in the request data, a search result, asillustrated in FIG. 10. Thus, in the screen illustrated in FIG. 10,players are displayed, in an identified manner, who are indicated asopponents to beat in the event data included in the request data. Thus,the display control section 38 may display a portion relating to a userspecified as an individual with a bounty in an identified manner. Then,in this case, a request for capturing a play image appropriate to theevent of beating the player in question may be accepted by participatingin the game in question. That is, in this case, agreement request datamay be generated on the basis of request data that indicates, as eventdata, that the player playing in the game server in question must bebeaten. In this case, participation in a game corresponds to requestdata selection operation. Then, in this case, agreement request data isgenerated in response to participation in the game and stored in thestorage section 12 b. Then, control is exercised so that a play imageappropriate to an event of beating the player in question is captured.

Further, in the step of S201, a search condition may be transmittedwhich states that beating the player playing in the game server in whichthe user A is logged as the player A must be specified as an event datavalue in the step of S201.

Still further, for example, all identification information of the playerspecified as an individual with a bounty by all players other than theplayer A may be displayed in a list in the steps of S201 to S204. Stillfurther, for example, all identification information of the playerspecified as an individual with a bounty by a player registered as afriend of the player A in the server 10 may be displayed. Then, theagreement request data about the event of beating a player may begenerated. The player is selected by the player A from among the aboveplayers.

A description will be given next of an example of a flow of a capturenotification process performed by the game system 1 according to thepresent embodiment with reference to the flowchart illustrated in FIG.11. This process is performed when an event of beating the player Xoccurs while the user A plays the game A. We assume here that theagreement request data illustrated in FIG. 5 is stored in the agreementrequest data storage section 30 of the capture notification device.

First, the capture control section 42 of the capture notification devicecaptures a play image in response to detection of the event by thedetection section 40 of the capture notification device (S301). Whatkind of play image is captured here is determined on the basis of thevalues of the captured image type data and timing relationship dataincluded in the agreement request data as described above. A capturedimage or movie obtained by capturing a play image is associated withmetadata and stored in the captured image storage section 44 asdescribed above. Here, for example, a captured movie based on playimages that appear from three minutes before to three minutes after theoccurrence of an event of beating the player X is stored in the capturedimage storage section 44 as described above.

Then, the display control section 38 of the capture notification deviceindicates, on the display, that a play image has been captured (S302).Then, the capture notification section 46 of the capture notificationdevice transmits to the server 10 the notification associated with theagreement request ID that is, in turn, associated with the event datarepresenting the event that occurred in the agreement request data. Thenotification in question will be hereinafter referred to as a capturenotification. Then, the capture notification acceptance section 58 ofthe server 10 accepts the capture notification in question (S303).

Then, the request data management section 54 of the server 10 updates,to “Fulfilled,” the value of the fulfillment status data of the requestdata that includes, as a request ID, the agreement request ID associatedwith the capture notification that was accepted in the step of S303(S304). Then, the capture notification section 60 of the server 10transmits, to the capture request device, the capture notificationaccepted in the step of S303. Then, the capture notification acceptancesection 24 of the capture request device accepts the capturenotification in question (S305). Here, the capture notification section60 can identify, on the basis of the requesting player ID included inthe request data, the capture request device to which to transmit thecapture notification.

Then, the display control section 28 of the capture request deviceindicates, on the display, that the requested play image has beencaptured (S306). We assume here that the user B performs a givenconfirmation process. As a result, the confirmation process executionsection 26 of the capture request device transmits a confirmationnotification to the server 10. As a result, the confirmationnotification acceptance section 62 of the server 10 accepts theconfirmation notification in question (S307). The confirmationnotification is associated with the agreement request ID that wasassociated with the capture notification accepted in the step of S305.

Then, the reward issuance section 64 of the server 10 issues a reward tothe user A. The reward is based on the reward data value of the requestdata that includes, as a request ID, the agreement request ID associatedwith the confirmation notification indicated in S307. Here, for example,a reward is transmitted to the capture notification device. Then, thereward reception section 48 of the capture notification device receivesthe reward in question (S308). Then, the display control section 38 ofthe capture notification device indicates, on the display, that thereward has been received (S309), terminating the process illustrated inthe present example.

As described above, a captured image or movie may be associated with acapture notification. That is, the capture notification section 46 ofthe capture notification device may transmit a captured image or movie.Then, the capture notification acceptance section 24 of the capturerequest device may accept the captured image or movie in question. Inthis case, the user B can confirm, by viewing the captured image ormovie in question, that the requested play image has been captured.Further, in the above process example, the user A is notified that areward has been received because the display indicates a message to thateffect. However, the manner in which the user is notified is not limitedto what indicates on the display. For example, an email informing that areward has been received may be transmitted to the mail address of theuser A. Further, an application through which the above notification canbe received may be installed in the smartphone owned by the user A.Then, the user A may be notified of the receipt of a reward via networkservice to which the application connects.

Further, the capture notification section 46 of the capture notificationdevice may upload a captured image or movie to an image publishing siteor other site as described above. Then, a site address such as that ofan image publishing site or other site where the captured image or moviein question can be browsed may be associated with a capturenotification. That is, the capture notification section 46 of thecapture notification device may transmit the site address where thecaptured image or movie in question can be browsed. Then, the capturenotification acceptance section 24 of the capture request device mayaccept the address in question. Then, the user B may confirm thecaptured image or movie, for example, by accessing the URL in question.

It should be noted that a process may be performed that indicates thefulfillment of the request in question in response to a reward. Forexample, the reward reception section 48 may delete the agreementrequest data, associated with the reward in question, from the agreementrequest data storage section 30. Then, the display control section 38 ofthe capture notification device may indicate, on the display, that therequest has been fulfilled.

It should be noted that if a given period of time elapses after acapture notification has been transmitted to the capture request devicein the step of S305, the request may be considered as fulfilled, and thereward issuance section 64 may issue a reward.

Further, for example, an evaluation of a captured image or movie may beassociated with a confirmation notification. Then, reward points to beissued may be determined on the basis of the evaluation.

Still further, for example, when captured movies appropriate to theevent of beating the player X are transmitted to the client 12-2 from avariety of players, the client 12-2 may create a collection of moviesmade up of the plurality of captured movies in question. Then, thecollection of movies in question may be uploaded to an image publishingsite or other site. At this time, for example, the collection of moviesmay be uploaded after having been worked on so that the name of thebeaten player, and the player X here, or the name of the player who beatthe player X, does not appear.

Still further, data for responding to the event of beating the player Xand replaying may be transmitted to the client 12-2 rather than movies.Then, the client 12-2 may generate a movie appropriate to the event ofbeating the player X by executing the game program and replaying on thebasis of the data. Here, among examples of data for replaying are keylog data, position coordinate data representing the positon of theplayer's character object, and posture data representing the posture ofthe player's character object.

The display control section 38 of the capture notification device mayexercise control so that a star symbol is arranged, in a game playimage, to the left of the name of the player indicated as an opponent tobeat in the event data included in the agreement request data asillustrated in FIG. 12. Further, the display control section 38 of thecapture notification device may arrange, in a game play image, a starsymbol near a player object CO who is indicated as an opponent to beatin the event data included in the agreement request data as illustratedin FIG. 13. FIG. 13 illustrates a character object CO(a) associated withthe player A, a character object CO(t) associated with a player T, and acharacter object CO(x) associated with the player X. In the imagesillustrated in FIGS. 12 and 13, players are indicated in an identifiedmanner. These players are indicated as opponents to beat in the eventdata included in the request data. Thus, the display control section 38may indicate, in an identified manner, a portion that relates to aplayer specified as an individual with a bounty within a play image.This makes it easier for a game player to identify, during play of thegame, a player to beat such as a player for whose beating a reward canbe gained.

FIG. 14 is an explanatory diagram schematically illustrating an exampleof software hierarchy of a program executed by the client 12 accordingto the present embodiment. Among programs executed by the client 12according to the present embodiment are an operating system, a captureutility that is on a layer above the operating system, and a gameprogram and a request/agreement utility that are on a layer above thecapture utility. The capture utility corresponds, for example, to thedetection section 40, the capture control section 42, the captured imagestorage section 44, and so on. The game program corresponds, forexample, to the game process execution section 36, and so on. Therequest/agreement utility corresponds, for example, to the requestsection 20, the capture notification acceptance section 24, theconfirmation process execution section 26, the request search section32, the agreement processing section 34, the capture control section 42,the capture notification section 46, the reward reception section 48,and so on. Further, the request/agreement utility may perform a processto display a screen that contains a list of game servers illustrated inFIG. 10 and that to display, in an identified manner, a player to beatin a play image generated by a game program as illustrated in FIGS. 12and 13.

It should be noted that a player specified as an individual with abounty may be detected by the game program layer rather than the captureutility layer. Further, the detection may be conducted by detecting acharacter string such as “The player X was beaten” that appears, forexample, on the screen by the operating system layer. Still further,beating of the player in question may be detected as a result of theuser performing an explicit operation.

It should be noted that the present invention is not limited to theabove embodiment.

For example, a request may be agreed to by exchanging a captured imageor movie rather than explicitly. More specifically, we assume, forexample, that the player A beats the player X without knowing that theplayer B has specified the player X as an individual with a bounty. Inthis case, a captured movie appropriate to the event in question ofbeating the player X may be transmitted from the client 12-1 to theclient 12-2.

Further, for example, a condition such as expiry date may be associatedwith request data or agreement request data. Then, if the condition inquestion is satisfied such as when the expiry date is overdue, therequest data or agreement request data in question may be invalidatedand deleted. More specifically, we assume, for example, that event datarepresenting an event about a game is included in agreement requestdata. In this case, the agreement request data in question may bedeleted when the player, the user using the client 12 that stores theagreement request data in question, no longer participates in the gamein question. Still further, the agreement request data in question maybe deleted when the individual with a bounty specified in the event datathat is included in the agreement request data no longer participates inthe game in question.

Still further, for example, the request information RI associated withinvalidated request data may be not arranged in the list screen. Stillfurther, the request information RI associated with invalidated requestdata arranged in the list screen may appear in a manner different fromthe other request information RI. Still further, it may be impossiblefor the user to agree to the request associated with the requestinformation RI associated with invalidated request data even if he orshe performs an operation of selecting the request information RI.

Still further, a captured movie may be delivered through live streaming.For example, a captured movie may be buffered first, and then uploadedto a site providing a live streaming service and published rather thanbeing stored in the storage section 12 b of the client 12. Then, the URLof the site in question may be transmitted from the capture notificationdevice to the capture request device.

Further, the server 10 may include a plurality of enclosures. Further,sharing of roles between the server 10 and the clients 12 is not limitedto the above. Further, the server 10 and the clients 12 may be combinedin one piece.

How the game whose play image is to be captured is implemented in thepresent embodiment does not specifically matter. For example, thepresent embodiment may be applied to play image capture in a game thatindicates a play image via a browser installed in the client 12 and thatis executed on the server side, for example. Further, the presentembodiment may be applied to play image capture in a game that isexecuted on the client side. Still further, the present embodiment maybe applied to a game that is made possible by coordination between theprograms installed in the server and the client.

Still further, for example, in addition to the above, capture conditiondata may be a parameter managed within the system of the client 12 and acombination of parameters managed in the played game.

Here, among examples of parameters are a user ID, a region to which theuser belongs, a user's gamer rank (trophy rank, gamer score), and gametitles owned. Among other examples of parameters managed within thesystem are playing time of a specific game and shooting time (capturetime of a play image).

Further, among examples of parameters managed in the played game are thenumber of trophies gained in a specific game, the number of opponentsbeaten, a combo count, a score, and the best time. In addition to theabove, a map ID, a location ID, an enemy object ID, an item object ID,an event ID, and a trophy ID in the game are among examples ofparameters managed in the played game. In addition to the above, thenumber of item objects gained, times cleared, times when the trophieswere gained, start times, the number of opponents beaten, and change inscores in the game are among examples of parameters managed in theplayed game. In addition to the above, change in transactions betweenthe clients 12 and the server 10, volume in voice chat, and change inspeaker count are among examples of parameters managed in the playedgame.

Still further, the above specific character strings and characterstrings in the drawings are illustrative, and the present invention isnot limited to these character strings.

1. An information processing device comprising: a capture condition datatransmission section adapted to transmit capture condition datarepresenting a condition for capturing a play image that indicatesdetails of a game in progress; and a confirmation process executionsection adapted to execute a confirmation process for capture of theplay image appropriate to the condition represented by the capturecondition data.
 2. The information processing device of claim 1, whereinthe capture condition data transmission section transmits the capturecondition data representing a condition to the effect that, in the game,an event must occur that relates to a user who is different from a userusing the information processing device and a user using a deviceadapted to capture the play image, and the confirmation processexecution section executes a confirmation process for capture of theplay image in response to occurrence of the event.
 3. The informationprocessing device of claim 1 further comprising: an acceptance sectionadapted to accept a captured image of the play image.
 4. The informationprocessing device of claim 1 further comprising: an acceptance sectionadapted to accept an address of a site that allows a captured image ofthe play image to be browsed.
 5. An information processing devicecomprising: a capture condition data storage section adapted to storecapture condition data that represents a condition for capturing a playimage that indicates details of a game in progress; and a notificationsection adapted to notify capture of the play image appropriate to thecondition represented by the capture condition data.
 6. The informationprocessing device of claim 5, wherein the capture condition data storagesection stores the capture condition data representing a condition tothe effect that, in the game, an event must occur that relates to a userdifferent from a user who is notified of capture of the play image and auser using the information processing device, and the notificationsection notifies capture of the play image in response to occurrence ofthe event.
 7. The information processing device of claim 5 furthercomprising: a display control section adapted to display, in anidentified manner, a portion that relates to a user different from auser who is notified of capture of the play image and a user using theinformation processing device.
 8. The information processing device ofclaim 5, wherein the notification section transmits a captured image ofthe play image.
 9. The information processing device of any one of claim5, wherein the notification section transmits an address of a site thatallows the captured image of the play image to be browsed.
 10. Aninformation processing method comprising: transmitting capture conditiondata representing a condition for capturing a play image that indicatesdetails of a game in progress; and executing a confirmation process forthe capture of the play image appropriate to the condition representedby the capture condition data.
 11. An information processing methodcomprising: storing capture condition data representing a condition forcapturing a play image that indicates details of a game in progress; andnotifying capture of the play image appropriate to the conditionrepresented by the capture condition data.
 12. A non-transitory,computer readable recording medium containing a program, which whenexecuted by a computer causes the computer to perform actions,comprising: by a capture condition data transmission section,transmitting capture condition data representing a condition forcapturing a play image that indicates details of a game in progress; andby a confirmation process execution section, executing a confirmationprocess for capture of the play image appropriate to the conditionrepresented by the capture condition data.
 13. A non-transitory,computer readable recording medium containing a program, which whenexecuted by a computer causes the computer to perform actions,comprising: by a capture condition data storage section, storing capturecondition data that represents a condition for capturing a play imagethat indicates details of a game in progress; and by a notificationsection, notifying capture of the play image appropriate to thecondition represented by the capture condition data. 14.-15. (canceled)16. An information processing system comprising: a first informationprocessing device and a second information processing device, whereinthe first information processing device includes a capture conditiondata transmission section adapted to transmit, to the second informationprocessing device, capture condition data representing a condition forcapturing a play image that indicates details of a game in progress, thesecond information processing device includes a capture condition datastorage section adapted to store the capture condition data, and anotification section adapted to notify the first information processingdevice of capture of the play image appropriate to the conditionrepresented by the capture condition data, and the first informationprocessing device further includes a confirmation process executionsection adapted to execute a confirmation process for the capture of theplay image appropriate to the condition represented by the capturecondition data.
 17. (canceled)